Currently, clients fail to parse the autocomplete model. Context can be found in this thread.

This issue is not reproducible in all cases. Clients (tested in VS Code only) may resolve the autocomplete model based on the client configuration and feature flags before parsing the provider and model data from the connected Sourcegraph instance. However, if we disable the client configuration and feature flags (make resolveDefaultModelFromVSCodeConfigOrFeatureFlags always return null), creating the provider configuration for autocomplete consistently fails (at least for me).

The current implementation of codyLLMConfigurationResolver returns:

• The code completion provider ID as provider
• The code completion model ID prefixed with the provider ID as completionModel.

This PR proposes to return only the model ID as completionModel. This adjustment allows clients to correctly resolve the provider and model for completions.

I don’t believe this is a comprehensive solution or that it aligns with the new model configuration approach. With this change, chatModel and fastChatModel use model IDs prefixed with providers, while code completions use a combination of provider and completionModel (without the provider prefix as it’s a separate field).

This PR is primarily for demonstration purposes. For more details, refer to the referenced Linear thread.

Test plan

Tested locally in VS Code.

Configuration used for testing

• site config

"completions": {
    "provider": "sourcegraph",
    "accessToken": "TOKEN",
    "endpoint": "https://cody-gateway.sgdev.org",
    "completionModel": "anthropic/claude-instant-v1",
    // ...limits
} 

• Cody for VS Code with resolveDefaultModelFromVSCodeConfigOrFeatureFlags always returning null